Had that idea before - no difference :( I fear the early adopters curse. Have also reduced most other UI related code in my app to check any interferences . Will see if I manage to build a smaller example for a bug report sometime next week if nothing pops up here. thx anyway!" appreciate any input.
if it is of matter: macOS Ventura but not latest XCode. I will try that as well.
Volker Runkel
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Trying as well, same issue. No workaround. When opening a document the underlying managedobject context is created on another thread than when creating a a new document. Just found this post after adding my own.
Threading deadlocks can be easily reproduced by saving the context :( The only good thing for me is I could switch within 30s to a non document based app and add more logic. Hopefully the document woes will be solved soon and I can switch back again ... (that really is a nice touch of swiftui. Funny is that the CoreData problems were similar the first two years working with nspersistentdocument. I have built a production app when it was new and cursed even more than now with SwiftData.
Thanks a lot- Currently I switched to a non doc app to develop some more features but will give this solution a try as well. I had considered a similar approach but decided to wait for 14.1 ... i guess the SQLite errors might be unrelated but none the less good for future problems ;)
Thanks for the input really appreciated! I will try the macOS approach, since I had already a similar approach but from seeing your code had a wrong call. For the iOS side I will have an iPad available the next weekend. BTW: Using AudioQueue the high samplerate works well as I have tested last night But the approach is much less nice than the AVAudioEngine.
Running the above code gives sample rates that do not come from the selected audio device. Digging deeper the inputNode.auAudioUnit is not identical to the audio input device selected in System preferences. Yet if I ask the system for the current input device i do get my highness usb microphone as input device. So the AVAudioEngine is using another input - maybe an aggregated device :| At least that gives me a new starting point for further analysis.